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REMARKS 



Status of the Claims 



• Claims 1-20 are pending in the Application after entry of this amendment. 

• Claims 1-20 are rejected by the Examiner. 

• No claims are amended by Applicant. 



Claim Rejections Pursuant to 35 U.S.C. §103 (a) 

Claims 1-20 stand rejected pursuant to 35 U.S.C. § 103(a) as being unpatentable over 
U.S. Patent Publication No. US 2004/0025 1 17 to Ingersoll in view of U.S. Patent Publication 
No. US 2002/0161801 to Hind. 

Applicant respectfully traverses the rejection. On page 2-3 of the Office Action dated 
1 1/14/2006, Examiner states: 

"Second, Applicant argues that there is no teaching in Ingersoll or Hind of translating 
characters of the native format into tokens, parsing the tokens and producing XML 
file by converting the first native format to an XML format, In response to Applicant's 
argument, the Examiner states that as previously stated Ingersoll discloses translating 
characters of the native format into tokens, parsing the tokens and producing XML 
file by converting the first native format to an XML format in paragraph 0021 
Ingersoll where syntactic transformations using a common syntactic base and EDI 
and OAG documents are converted in to an XML (common syntactic base) paragraph 
0021, Ingersoll." (Office Action, pages 3-4). 

Ingersoll at paragraph 0021 states: 

"[0021] FIG. 2 depicts supplier processing of incoming purchase orders destined for 
four disparate systems. Incoming purchase orders originate from three sources 201, an 
EDI buyer, an online store customer and an OAG-compliant buyer. The native 
formats utilized by the three sources 201 may include EDI, XML and OAG. Four 
target systems 206 include an SAP Financial system, an SAP MRP system, a Biz IQ 
system and a Grainger shipping system. The native formats accepted by these target 
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systems 206 include IDOC, BAPI, OAG and a custom API. In this system, a web 
services engine 211 performs semantic transformations using a common syntactic 
base. For instance, EDI and OAG documents are converted to XML, as a common 
syntactic base. Transformations from XML to XML handle semantic differences 
between the source and target document. XML documents may be reconverted to 
native formats such as EDI, OAG, IDOC, or BAPI. The syntactical transformations to 
and from XML may be handled as part of the web services engine 211 or by the 
interfaces or adapters 202, 205 associated with the source 201 and target 206." 
(paragraph 0021). 

Respectfully, Applicant notes that Ingersoll, in paragraph 0021, fails to disclose 
translating "characters" of the native non-XML format into "tokens". Applicant can find 
neither "characters" nor tokens in Ingersoll paragraph 0021. Simply, Applicant submits that 
Ingersoll does not teach translating characters of the non-XML flat file native format into 
tokens as recited in Claim 1 . Ingersoll fails to teach this step of Claim 1 . 

Also, Applicant notes that Ingersoll, in paragraph 0021, fails to disclose "parsing" the 
"tokens". Applicant can find neither the act of parsing nor a teaching that parsing is 
performed on tokens that were translated from characters of a non-XML file in paragraph 
0021 . Simply, Applicant submits that Ingersoll does not teach parsing tokens translated from 
characters of a non-XML flat file as recited in Claim 1 . Ingersoll fails to teach this step of 
Claim 1. 

Also, Applicant notes that Ingersoll, in paragraph 0021, fails to disclose producing an 
XML file by converting the non-XML flat file native format to an XML format with the use 
of at least one annotated schema comprising a model of a flat file. Applicant can not find in 
paragraph 0021 where Ingersoll teaches using a model of a flat file. Applicant can not find in 
paragraph 0021 where Ingersoll teaches an annotated schema comprising a flat file. Applicant 
can not find in paragraph 0021 any conversion of a native non-XML flat file format into an 
XML specifically using an annotated schema comprising a model of a flat file. Simply, 
Applicant submits that Ingersoll does not teach producing an XML file by converting the first 
native format of a non-XML flat file to an XML format with the use of at least one annotated 
schema comprising a model of a flat file as recited in Claim 1 . 
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Clearly, Ingersoll fails to teach (1) translating characters of the non-XML flar file 
native format into tokens, and (2) parsing the tokens that were translated from the characters, 
and (3) producing an XML file by converting the native format to an XML format with the 
use of at least one annotated schema comprising a model of a flat file. Applicant respectfully 
submits that the method and elements presented in Claim 1 are simply not taught by 
Ingersoll. 

Applicant agrees with the statement in the present Office Action on page 4 that 
"Ingersoll however does not explicitly disclose the tokens and the annotations as claimed." 
However Applicant respectfully disagrees that Hind teaches the tokens and annotations as 
claimed in Hind paragraph 0097 lines 13-21. At this citation, Hind teaches: 

'This attribute value is then written to the XML data buffer, followed by a closing 
quotation mark. This process is repeated for each attribute in the attribute list (where 
each attribute name/value pair is preferably separated from the preceding pair using a 
blank space), after which processing continues at Block 655. (While the preferred 
embodiment is described in terms of separating output tokens in the XML document 
using blank spaces, it will be obvious than other separators may be used equivalently, 
such as multiple blank spaces and/or tab character(s) and/or line return(s).)" 
(paragraph 0097, lines 13-21). 

Applicant feels it is important to consider the entire teaching of Hind and not just a 
selected out-of-context citation. Hind teaches at paragraph 0097, lines 1-12: 

"Writing each attribute's information preferably comprises writing a blank space to 
follow the node name written out in Block 620. This blank space is then followed by 
the attribute name, where the attribute name is found using the starting position and 
length from the attribute list along with the data buffer pointer to index into the 
mXML data buffer, and then (i) an optional blank space, (ii) an equal sign, (iii) 



another optional blank space, and (iv) an opening quotation mark." (paragraph 0097, 
lines 1-12). 
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Thus, Hind teaches, via paragraph 0097 and Figure 6A and 6B, the writing of node 
names to an XML buffer (Block 620 of Figure 6A), followed by the acquisition of an 
attribute list (Block 640, Figure 6A), and the writing of the attributes to the XML buffer 
(Blocks 650-655 of Figure 6B). Applicant respectfully submits that the "tokens" of paragraph 
0097 are another name for "attributes". Hinds teaches in paragraph 0096 that: 

"The attribute list is obtained from the node specification at Block 640. The list is 
checked (Block 645) to see if it is empty. If not, Block 650 writes the information for 
each attribute into the XML buffer and moves the buffer pointer." (paragraph 0096). 

Applicant respectfully submits that if the attribute list of Hind is obtained or based 
from the node specification, then the node specification implies a node structure. Applicant 
notes that a first step of Claim 1 is "receiving the non-XML flat file in a native format". 
Applicant respectfully submits that, to the best of Applicant's understanding, a non-XML flat 
file does not have a node structure and is therefore without nodes. Since a non-XML flat file 
does not have nodes, then there can be no node-based attribute for the process of Hind to use. 
Thus, Hind does not teach reception of a non-XML flat file and translating the characters of 
the non-native flat file format into tokens as recited in Claim 1 because Hind teaches writing 
node-based attribute values into an XML buffer in paragraph 0097. If the attributes are node- 
based, then they cannot be from a non-XML flat file. No mention is made by Hind of the use 
of the characters translated into tokens and then producing an XML file by converting the 
non-XML flat file native format into an XML document format with the use of at least one 
annotated schema comprising a model of a flat file as recited in Claim 1. 

Simply put, Applicant respectfully disagrees with the Examiner contention that " Hind 
teaches the tokens and the annotations as claimed in paragraph 0097 lines 13-21" as stated on 
page 4 of the Office Action dated 1 1/14/06. Applicant disagrees because the "tokens" of Hind 
are node-based attributes which seemingly cannot originate from a translation of characters of 
a non-XML flat file that does not have nodes. 

Overall, the combination of Ingersoll and Hind fails to teach all of the elements of 
Claim 1 in a coherent and combinable manner. Specifically, the combination of Ingersoll and 
Hind fails to teach a method which specifically translates characters of a non-XML flat file 
native format into tokens, and then parses the tokens to produce an XML file by converting 
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the flat file native format to an XML format with the use of at least one annotated schema 
comprising a model of a flat file. The combination of Ingersoll and Hind simply fails to teach 
the specific elements of the method of Claim 1 . Applicant respectfully submits that every 
element of Claim 1 must be identified in a combination of references, including the non- 
XML flat file input, including the translation of characters of the non-XML flat file into 
tokens, including the parsing of the tokens, including the production of an XML file by using 
an annotated schema comprising a model of a flat file. Since these elements are not taught in 
a coherent method by the combination of Ingersoll and Hind, then, no prima facie case of 
obviousness can be made on Claim 1 and its dependent claims according to MPEP §2143.03. 
Since independent Claims 9 and 16 recite similar elements that are not disclosed in the 
combination of Ingersoll and Hind, then no prima facie case of obviousness can be made on 
Claims 9 and 16 and their respective dependent claims according to MPEP §2143.03. 

Conclusion 

Applicant respectfully submits that the above arguments effectively traverse the 
rejections of the cited art by demonstrating that all elements of the pending claims are not 
taught by the combination of Ingersoll and Hind. Applicant respectfully requests 
reconsideration for all pending claims and a Notice of Allowance. 
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